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File: PGPB 



Nov 14, 2002 



DOCUMENT- IDENTIFIER: US 20020169887 Al 

TITLE: System and method for assisting in controlling real-time transport protocol 
flow through multiple networks via screening 



Application Filing Date : 
20010427 

Summary of Invention Paragraph : 

[0023] Certain simple gateways, such as, but not limited to, the Cisco AS5300, can 
forward SIP-based call requests to a SIP proxy server. Unfortunately, these 
gateways have low densities and frequently lack the sophistication of softswitches 
in setting up routing policies. These routers, therefore, cannot be interconnected 
to create networks without a Softswitch controller. 

Brief Description of Drawings Paragraph : 

[0046] FIG. 12A is a flow chart that illustrates steps taken by a SIP proxy to 
analyze a SIP message. 

Detail Description Paragraph : 

[0059] SIP is a protocol that has a number of key mechanisms defined. A first SIP 
mechanism is called a "register" message. When sent to a SIP proxy server, this 
message indicates that the endpoint is capable of receiving a communication for a 
specific user. This "register" message binds the physical IP address to the user 
using the IP address. A second SIP mechanism is the "invite" message. This message 
is sent to another endpoint to request a communication session. The "invite" 
message is sent all the way to the endpoint of the receiver of the communication. 
The receiver of the "invite" will then respond with an OK message indicating that 
the communication is accepted. When there are more than a few endpoints, or when 
there are endpoints that need certain features, a SIP proxy server acts as a go- 
between. The SIP proxy server receives and forwards the "invite" messages that are 
received for its users that have previously sent a "register" message. 

Detail Description Paragraph : 

[0060] FIG. 2 provides a detailed illustration of interaction between two SIP 
agents via a SIP proxy . For example, if a user sends a "register" message 242 from 
a first SIP user agent 244, a SIP proxy server 246 acknowledges the registration. 
Then, if a second SIP user agent 248 sends an first "invite" message 252 for the 
user that transmitted the "register" message" 242, the first "invite" message 252 
is received by the SIP proxy server 246. The SIP proxy server 246 then transfers a 
second "invite" message 254 to the first SIP user agent 244. If the first SIP user 
agent 244 is willing to accept communication from the second SIP user agent 248, 
the first SIP user agent 244 transmits a message of approval to the SIP proxy 
server 246 which is then transmitted to the second SIP user agent 248. 

Detail Description Paragraph : 

[0061] A third SIP mechanism is the "bye" message, which unilaterally sends a 
communication session, and frees all of the network resources in use. Either side 
of a communication can send a "bye" message at any time. One notion embodied in the 
SIP architecture is that the user has mobility wherein the user can send a 
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L9: Entry 6 of 8 File: PGPB Sep 12, 2002 



DOCUMENT -IDENTIFIER: US 20020126701 Al 

TITLE: System and methods for using an application layer control protocol 
transporting spatial location information pertaining to devices connected to wired 
and wireless internet protocol networks 



Application Filing Date : 
20011030 

Detail Description Paragraph : 

[0145] Once the use has the server address it can send the SIP REGISTER message 
containing the SL information in its body. The Registrar server that behaves like 
the Authentication Server (AUS) required in the SLO architecture will authenticate 
the initial message. If the contacted SIP server is not a Location Server (LS) the 
message has a specific header for discovering the Location Server. It will be 
indicated in the SIP header "Require" sent in the REGISTER message. Hence, for 
indicating that the incoming message contains Spatial Information and needs to be 
processed by a Location Server, the SIP REGISTER will have the following header: 
"Require: SLO - server " . It indicates that the user is registering his location and 
needs a Spatial Location Server to manage this data. In case that the server 
contacted has no SL capabilities the user will receive back a response where the 
"Contact:" header includes the address of the new SIP server, which can handle that 
message. An example would be like this: "Contact: slo-server.nokia.com". 

Detail Description Paragraph : 

[0151] Since the SLO is a new service, it remains a possibility that the contacted 
SIP registrar does not support this feature. There are two possibilities, the first 
one is trying to register with the closest SIP Registrar and wait for its response, 
and the other solution would be to use the OPTIONS message for querying beforehand 
the Registrar's capabilities. In the former case, if the registrar can handle a SLO 
message the registration will succeed, otherwise the User Agent receives a 300 
response with the address of a SLO enabled SIP Registrar . In the other case, the 
User Agent needs to negotiate this capability with the registrar. The client will 
send an OPTIONS message to the registrar for indicating that he needs a SLO based 
registrar. The registrar can send back a 2 00 OK response, which means that it can 
manage this type of registration. Otherwise, the registrar returns a 300 Multiple 
Choices response, which means that the requested capability can be accessed through 
the proxy given by the "Contact:" field. 

Detail Description Paragraph : 

[0211] The CSCF (with SIP Proxy /Registrar capabilities) will accept the user 
registration. Furthermore, the CSSF sends the User Information either to the HSS 
(Signalling Interface Cx) or the Presence Server if such an entity . exists, as 
shown. After this the user is registered and his situation is available for other 
services. If the Presence Server does not exist, then the HSS will behave like a 
similar Presence Server. At this point is a matter or re-using or not overloading 
existing entities. 
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L26: Entry 1 of 1 File: PGPB Jan 23, 2003 



DOCUMENT- IDENTIFIER: US 20030018704 Al 
TITLE: Network presence and location agent 



Application Filing Date : 
20010308 

Brief Description of Drawings Paragraph : 

[0015] FIG. 8 shows a message flow for user dereqistration ; 
Brief Description of Drawings Paragraph : 

[0016] FIG. 9 is a high level block diagram showing how a SIP NPL agent may be 
employed in connection with an IP network; 

Brief Description of Drawings Paragraph : 

[0017] FIG. 10 shows a message flow for user registration, for a SIP based 
embodiment; and 

Brief Description of Drawings Paragraph : 

[0018] FIG. 11 shows a message flow for retrieval of presence/location information 
in response to a request from an application, for a SIP based embodiment. 

Detail Description Paragraph : 

[0027] Of course, it is possible to use other protocols for communication between 
the wireless network 26 and the NPL agent 21. For instance, rather than 
communicating with the wireless network 261 through the SMSC 28, the NPL agent 21 
may communicate directly with the wireless network 26 using XML over SS7 (as shown 
in FIG. 2) . As anoth er example, TCP/IP may be used to connect to some of th e 
netw ork nodes cg,rectJ y. Similarly, Session Initiation Protocol ( SIP ) may be used, 
as described further belowT^"^ ~ 

Detail Description Paragraph : 

[0036] The^push agent 47 publishes presence or location information to applications 
44 wittiout requiring applications 44 to request the information. The push agent 4 7 
relies on the wireless service provider's HLR/ Mobile Switching Center (MSC) to 
proactively push notification of the user's registration or dereqistration via the 
wireless network 43. In one embodiment, the presence/location information is pushed 
to the push agent 47 via TCP/IP in the form of a Serving System Message according 
to J-STD-025 (TIA/ATIS Internet Standard, "Lawfully Authorized Electronic 
Surveillance", December 1997). Alternatively, XML over TCP/IP may be used. The push 
agent 47 is also capable of handling other types of messages which contain the user 
presence and location information from the wireless network via TCP/IP. The 
messages are decoded by the push agent 47, and the presence/location information is 
published to the applications using XML over HTTP and TCP/IP. 

Detail Description Paragraph : 

[0058] In the case of user deregistration, a J-STD-025 Serving System Message will 
be generated by the HLR 46 when the MSC issues a MobileStationlnactive message for 
a mobile device. The presence/location information will be published to the 
application 44. The process, as shown in FIG. 8, is as follows: 



http://westb^s:9000^in/gate.exe?f=TOC8&state=en2egl .48. 1 &ESNAME=KWIC&HTLNE. . . 1/1 8/06 



Record Display Form 



Page 1 of 1 



Previous Doc 



Next Doc 
First Hit 



Go to Doc# 




L9: Entry 1 of 8 



File: PGPB 



Feb 5, 2004 



DOCUMENT- IDENTIFIER: US 20040024902 Al 
TITLE: Megaco protocol with user termination 



Application Filing Date : 
20020618 

Detail Description Paragraph : 

[0019] The media gateway controller MGC is the part of the gateway which commands 
the media gateway to connect and release the connections. In other words, the MGC 
performs the control plane functions and comprises the intelligence. The media 
gateway controller may, for. example, be controlled by a so called soft switch or a 
SIP (Session Inititiation Protocol) proxy via which the actual signaling is routed, 
part of the soft switch or the SIP proxy, or it may be a network node via which the 
signaling is routed. Depending on how the MGC is implemented, it may be involved in 
signaling and may co-operate with other signaling protocols, such as SIP or it can 
receive control information with some protocol, such as Parlay API or SOAP (Simple 
Object Access Protocol, defined by the World Wide Web Consortium W3C) . The media 
gateway controller according to the invention is described in more detail below 
with the connection model and with FIGS. 2 to 5 . One media gateway controller 
controls one or more media gateways. 

Detail Description Paragraph : 

[0045] The CPS 11 is responsible for control -plane management of the PMR 
communications. Its important role may require various functionalities which can be 
implemented in the following modules: "PMR server" --the application that handles 
the sessions for group memberships which are signaled with an appropriate session 
control protocol, such as SIP, established for the PMRoC communications, and 
manages the users profiles (call rights, group active membership, scanning 
settings, etc.); SIP Proxy /Location Server- -providing user location and routing 
functionalities of SIP signaling; SIP Registrar- -for user 

registration/ authentication; and Media Gateway Controller- -controlling the network 
entities involved in the IP layer data distribution according to the group & user 
specific information (membership, rights, scanning settings, etc.). 

Detail Description Paragraph : 

[0068] Referring to FIG. 4, once the UE knows the IP, address of the U-CPF it sends 
a SIP registration message 4^*1 to the U-CPF The SIP .registration message contains 
among other things user's SIP URL, port number in terminal for One-to One calls and 
scanning settings for One-to-One calls. It may contain also the mnemonic that the 
user wants to use for One-to-One calls. The foregoing parameters are parameters 
that may be sent to the UT. In response to message 4-1, the U-CPF sends message 4- 
2, which contains an authorization challenge. The UE responds by sending message 4- 
1', which is the previously sent SIP registration message 4-1, with authentication 
response . 



Previous Doc 



Next Doc 



Go to Doc# 



http://westbrs:9000toin/gate^ 1/18/06 



Record Display Form » 



Page 1 of 1 



Previous Doc 



Next Doc 
First Hit 



Go to Doc# 



□ 




L9 : Entry 2 of 8 



File: PGPB 



Jun 26, 2003 



DOCUMENT- IDENTIFIER: US 20030120813 Al 

TITLE: Apparatus and method for optimizing message sizes of textual protocols used 
in multimedia communications 



Abstract Paragraph : 

An apparatus and method for generating compressed SIP messages from full sized SIP 
messages and vice versa in order to decrease call set up time in an IP based 
communication system. During registration of a device, the invention caches the 
device's static information in the core network in a "Registrar/Location Server." 
Subsequently, during call set up, the device transmits its dynamic information to 
the SIP Agent in a compressed SIP message over an air interface. The SIP Agent 
retrieves the static information (from the Registrar/Location Server) along with 
the dynamic information in the compressed SIP message to generate a full sized SIP 
message. The SIP Agent forwards the full sized SIP message to a SIP Proxy, which is 
then transmitted to the IP system. Likewise, when a full sized SIP message is 
received from the IP system, the message is forwarded to the SIP Agent to generate 
a compressed SIP message for ultimate transmission to the device over the air 
interface . 

Application Filing Date : 
20011221 

Detail Description Paragraph : 

[0022] As previously stated, the static and default dictionary information is used 
by the MS 102 (138) and the SIP Agent 108 (124) to compress call setup messages for 
transmission over the air interface and to expand compressed messages received in 
the MS 102 (138) or SIP Agent 108 (124) . The static and default dictionaries 
generated using the information in the Register Message of FIG. 3 are shown in FIG. 
5. The static dictionary contains: 1) the contents of the first line (ssl.wcom.com; 
SIP/2.0); 2) the contents of the Via line (SIP/2. 0/UDP ssl .wcom. com: 5060) ; 3) the 
contents of the From line (BigGuy<sip: 1-314 -555 - llll@ssl . wcom. com>) - ; 4) the 
contents of the Content -Type line (application/SDP) ; 5) the contents of the 
Content -Length line (132); 6) the contents of the v line (0); 7) the contents of 
the o line (UserA 2890844426 2890844426 IN IP4 ssl.wcom.com); 8) the contents of 
the s line (Session SDP) ; 9) the contents of the c line (IN IP4 100.101.102.104); 
and 10) the contents of the t line (0 0) . The default dictionary contains: 1) the 
first contact address in the Register message (BigGuy<sip :UserA@here .com>) ; 2) the 
first m line in the Register message less the port number (m=audio . . . RTP/AVP 
0) ; and 3) the first a line in the Register message (a=rtpmap:0 PCMU/8000) . 
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L9 : Entry 5 of 8 



File: PGPB 



Sep 19, 2002 



DOCUMENT- IDENTIFIER: US 2 0020131395 Al 

TITLE: Session initiation protocol (SIP) user agent in a serving GPRS support node 
(SGSN) . ...... 



Application Filing Date : 
20011219 

Detail Description Paragraph : 

[0033] As will be explained in greater detail below, the SIP application server 216 
is a SIP-based service platform, i.e., may be implemented as a SIP 
proxy /redirect/ registrar server enhanced with service logic execution environment, 
APIs, web server, and media servers. The web server in the SIP AS 216 provides SIP 
session event triggered web services/applications, as well as HTTP event triggered 
SIP session service such as click-to-dial. A media server can be an E-mail server 
or Short Message Service Center, etc. The media servers may not necessarily reside 
in the same box as the SIP AS 216. A media server provides SIP session event 
triggered multimedia services, or vice versa, media triggered SIP session services. 



Detail Description Paragraph : 

[0034] More particularly, FIG. 4 is a diagram illustrating an exemplary SIP 
application server 216 in accordance with an embodiment of the present invention. 
The SIP Application Server 216 is a service centric SIP Proxy /Redirect/Registrar 
Server to provide voice/web/email combined multimedia services. In the embodiment 
illustrated, the SIP Application Server 216 includes a Call Server 1100, a Web 
Server 1102, a Media Server 1104, and an Execution Environment 1106. The Media 
Server 1104 may not necessarily be an integral part of a SIP Application Server. In 
certain embodiments, the SIP Application Server 216 is able to interface with 
external Media Servers (not shown) via IETF protocols whether it has internal Media 
Servers or not. 

Detail Description Paragraph : 

[0037] As a SIP Proxy /Redirect/Registrar Server, the SIP Application Server 216 
supports the SIP protocol to handle SIP requests and responses. In addition, it may 
support various service/application-orient- ed extensions to the baseline SIP. One 
is SIP extension of SIMPLE (SIP for Instant Messaging and Presence Leveraging) in 
order to support Presence and Instant Messaging services, as will be explained in 
greater detail below. 

Detail Description Paragraph : 

[0038] The Call Server 1100 is a SIP protocol engine that processes SIP requests 
and responses. The Call Server 1100 may support service/application-oriented 
extensions to the baseline SIP. Among these are the SUBSCRIBE and NOTIFY messages 
as specified in SIMPLE, which are used to implement Presence and other 
services/applications needed to dynamically arm and report a trigger event. The 
Call Server 1100 inter-works closely with the Execution Environment 1106, for 
example, in the same SIP Application Server. In typical cases, the Call Server 1100 
would hand the incoming SIP message to the Execution Environment 1106 for 
service/application execution decision. The Execution Environment 1106 would then 
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L13: Entry 1 of 4 



File: PGPB 



Oct 14, 2004 



DOCUMENT- IDENTIFIER': US 200^2 0*f6^T Al 
TITLE: Method of registering J ank deregistering 




user 



Application Filing Date : 
20020327 

Summary of Invention Paragraph : 

[0008] It has been appreciated by the inventor that all of these checks are not 
required for deregistration . Thus, the use of. the same message for registration and 
deregistration is disadvantageous- in that unnecessary processing is 'required. This 
unnecessarily slows down the process of deregistration and' also unnecessarily uses 
up the HSS resources . 

Detail Description Paragraph : 

[0026] In step SI, the user equipment 10 sends a register request from the user 
equipment to the P-CSCF 16. The purpose of this request is to register the users 
SIP (session internet protocol) uniform resource identifier with a CSCF 22 in the 
home network. This request is routed to the P-CSCF 16 because it is the contact 
point with the IP multimedia subsystem for the user equipment. The register message 
may include the following information: private identity, public identity, home 
domain name and the requested expiration time of the registration; content length, 
destination domain for the request; the IP address of SIP session allocated; the IP 
address of the user and authorisation information. 

Detail Description Paragraph : 

[0037] Reference will now be made to FIG. 3 which shows the procedure for the 
deregistration of an already registered user. Steps Tl to T5 are similar to steps 
SI to S5 of FIG. 2. However, there is no need to do the S-CSCF selection as this 
will have already been done. As the user is already registered, the next step after 
step T5 will be steps T6 and T7 which are the same as steps S18 and S19 of FIG. 2. 

Detail Description Paragraph : 

[0039] Reference will now be made to an embodiment of the present invention. In 
embodiments of the present invention, the register procedure is as outlined in 
relation to FIG. 2. However, a different procedure is provided for the 
deregistration procedure. In his regard, reference is made to FIG. 4. 

Detail Description Paragraph : 

[0040] FIG. 4 shows the signal flow during a deregistration procedure. In the first 
step 01, a register message is sent from the user equipment to the P-CSCF 16. This 
is the same as step SI in FIG. 2. In step Q2, the P-CSCF sends the register message 
to the I-CSCF 20. Again, this is the same as step S2 in FIG. 2. 

Detail Description Paragraph : 

[0041] Reference is made to FIG. 5 which shows the method carried out by the I-CSCF 
20. In step Al, the register message is received in step A2, the I-CSCF 20 checks 
the value of then expires header field which contains the requested expiry time in 
the SIP REGISTER message In particular in step A3, the I-CSCF checks if the value 
is 0. If it is, the next step is A4 . The value 0 is taken to indicate that the 
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L12 : Entry 1 of 1 



File: PGPB 



Aug 29, 2002 



DOCUMENT- IDENTIFIER : US 20020120760 Al 
TITLE: Communications protocol 



Application Filing Date : 
20010529 

Summary of Invention Paragraph : 

[0034] In any case, when proxy/redirector 306 receives the INVITE message, it 
communicates with a registrar/location sdrver 308 ,to retrieve the 'location 

(transport address) * corresponding to the SIP-URL used to indicate the callee. 
Typically, registration is perfo rmed by a terminal device upon startup utilizing a 
REGISTER message. When acting as a proxy, server 306 establishes the call by 
sending an INVITE to terminal device 3 04 and continues to act as- a go-between for 
the endpoints^ during the session*. When acting as a redi rector,' server 306 return s 
the aHfWo^nf hprm-inai — ri^H rp 304 to terminal device 300. which t hen establishes 
<:L gie^session directly with terminal device 30 4.' It should be noted' that /"while 
illustrated as two different machines, often t ^jjnes registrar 308 an d 
proxy/redirector 306 are implemented on the sam e machi ne . A lso, through the use o f 
the registration server , SIP provides for terminal mobility, i n addition to , ~~~ 
pe rsonal mobility . » " — 

Detail Description Paragraph : 

[0215] When the client sends this transaction to the server, the server will accept 
the transaction (using BLRemove . accept ) but all that means i§ that the server 
accepts the transaction- -this does not meajL-^ha-t--fehe--j^] c ^nt fan remove the entry 
fro m it's address book. The .client may ijejno've an address^ book entry only when it 
receives a BLRemove message from the server. ~ * — - 
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